A system architecture is the fundamental organization of a system representing various components of the system, their relationships to each other and the environment, and the principles governing the system's design and evolution. Systems may comprise numerous entities, including applications, subsystems, components, web services, interfaces (e.g., application program interfaces (API) and other user interfaces (UI)), function calls, and any other element that is capable of interaction.
System architecture and software design typically involves the initial definition of functional (or behavioral) and non-functional requirements (NFRs). Functional requirements define what particular functions a system will offer, such as printing a document or sending a welcome email to a customer. Non-functional requirements define what a system is supposed to provide in terms of, for example, security, usability, testability, scalability, and maintainability. That is, NFRs refer to information describing constraints and qualities of a system. For example, NFRs may define particular hardware and software to be used as well as a desired response to scaling demands and system failures or flaws.
Ideally, system and software development processes would take into account all important NFRs and define NFRs that are specific, measurable, achievable, and testable. NFRs are often technical in nature and may heavily impact the resulting software and system architecture. A significant investment in resources, including time, money, and personnel, is commonly made to address NFRs. Some steps for gathering requirements (e.g., NFRs) include defining the scope of the system/software, selecting gathering techniques, conducting interviews and requirement workshops, prioritizing requirements, documenting the requirements, reviewing and analyzing the requirements, and validating the requirements.
During the requirements gathering process, it may be desirable to determine as much as possible about the interactions between entities (or parties) in a system or software. Moreover, it may be desirable to gather as many requirements as possible as early as possible in the system and/or software development cycle. Typically, system/software interactions are discovered relatively late in the development cycle. Indeed, some interactions may only be discovered as the system/software evolves. Late discovery of system/software interactions often results in inefficient use of development resources and added costs to development projects. As a result, it may be difficult to estimate the time and costs associated with developing systems and software, and therefore, also difficult to plan for the release of such systems and software.
Accordingly, new systems, devices, and methodologies are desired to facilitate early and/or complete capture of the interactions between parties of a system and/or software to be developed and requirements associated with such interactions.